IBIS Macromodel Task Group Meeting date: 28 June 2016 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Intel: Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - Arpad reminded everyone that the July 5th meeting has been cancelled. ------------- Review of ARs: - Ambrish to check for a collaborator's feedback on his nearly ready new version of the Backchannel proposal. - In progress. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Walter: Motion to approve the minutes. - Bob: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: IO Buffer Reference Terminal proposal: - Walter: [sharing draft 5 of the Pin Reference BIRD] - This version contains lots of cleanup and detail improvements. - It is significantly improved over the last version and ready for a thorough review. - What do you do when you're simulating a device-in-action (DIA) and the rail voltages are not the same as the fixed [* Reference] values from the device under test (DUT) measurements? - This BIRD clarifies this by stating that the EDA tool should use the same model terminal as the reference terminal during DIA that was used as the reference node during DUT measurements/simulation. - Arpad: How do we know which node that is? - Walter: If any one of the [* Reference] values is 0.0, then the corresponding *_ref terminal was the reference terminal during DUT and should be used as such during DIA. - If the test fixture reference node at DUT is not connected to a Component Pin that is one of the *_ref terminals of the I/O buffer, then none of the five [* Reference] values would be 0.0. - In that case, this BIRD enhances the IBIS spec to define the POWER or GND signal_name that the EDA tool should use as the reference node for all I/O buffer terminal measurements. - Discussion: Bob noted that he was concerned about going back to this proposal and abandoning the DUT_Ref_term BIRD. He felt we were giving up on some progress that had been made on that BIRD including special handling for non- zero reference terminals and threshold testing. Walter noted that the special handling was no longer needed since the Pin Reference BIRD provides the actual local reference itself. In addition, he noted that the DUT_Ref_term BIRD did not handle the case in which all five [* Reference] values were non-zero. - Radek: This is certainly moving in the right direction. We should clearly state that a buffer model in general contains five terminals (*_ref), then we have to say what happens when any [* Reference] values are the same, which is an indication that the corresponding *_ref nodes are collapsed to the essentially the same node. Then we have the special cases with fewer terminals than the general case. We would certainly like to have this Pin Reference BIRD in case the connection to the reference node is different from any of the *_ref terminals. This is particularly useful for a power aware simulation. This is good, and we may also want to keep the DUT_Ref_term BIRD as well, and we can discuss that later. - Arpad: We have to be careful about saying the corresponding nodes are "collapsed into one node" when the [* Reference] values are the same. Even if the [* Reference] values are the same, one might have a quiet Pin vs. another with a noisy Pin providing the connection to their *_ref terminals at simulation time. - Radek: Agreed, we have to reconcile this specifically with the Pin Mapping. Here this BIRD is talking about the case where any [* Reference] values are the same and the value is zero, in terms of choosing one to use for the reference terminal. But we must have text to put this in context with Pin Mapping, which could allow those connections to be made separately. (Note: Walter added a line in the "Other Notes:" section of the BIRD draft to remind us to address this issue). - Walter: [Reviewing the three editorial changes upon which the BIRD relies, which are defined in the "Definition of the Issue" Section.] - 1. [Addition to Guideline #2 on page 9] - Pin name and signal_name are defined as coming from the data book, so we can't apply/enforce any special reserved-names rules with them. - 2. [New Guideline #15 to be added on page 10] - Definition of the way to interpret the meaning of the term "GND" and any Earth Ground Symbols seen in the document. - (Radek noted that he would like "unless otherwise noted" added to this section, as certain voltages like those for the I/V tables are not measured relative to the reference node. Walter added a note to the draft to remind us to address this). - 3. [New rule for the [Pin] section on page 21] - If two Pins have the same signal_name, they must have the same model_name. - Walter: [After reviewing the ECL example provided with the BIRD, in which none of the [* Reference] values are 0.0] - This handles the general case. - It's a simple change for the specification and the parser. - If this BIRD is passed, the editorial group's work becomes very simple. - We would know how to make measurements when the test fixture ground is provided by something other than one of the five *_ref terminals. - Discussion: Mike brought up the issue of how to choose one when multiple [* Reference] values are zero, and asked if we should state that any one of them could be used. Arpad reiterated his earlier point that we can't assume the corresponding *_ref terminals are shorted, and cited as an example Randy providing IBIS models that defined VSS and VSSQ. Walter replied that no one IBIS buffer in one of Randy's models would be connected to VSS and VSSQ, it would be connected to one or the other. Radek noted that he had used the term "collapsing" (into one node) in the context of not having a [Pin Reference] or a [Pin Mapping] specified. In the absence of those two, the values of the five [* Reference] values actually establish connectivity. If [Pin Reference] or [Pin Mapping] were specified it could provide enough information to override this apparent "collapsing" of the nodes into one when necessary. Radek suggested that we carefully spell out exactly what is done if neither [Pin Reference] nor [Pin Mapping] are provided, and then spell out how any assumptions we make when we only have the [* Reference] keywords are overridden or enhanced if [Pin Reference] and/or [Pin Mapping] are provided. Bob noted that he had expected this BIRD to do what Radek was describing, declare the reference node when none of the [* Reference] values were 0.0 and you need to pull out a "0V" reference from somewhere else on the component. He said he was fine with that, but felt we still needed to keep the DUT_Ref_term BIRD as well, particularly for thresholding issues. Radek agreed that we might want to keep both, though he noted that the thresholding discussion was tricky since it also could involve [External Reference]. Walter said he thought the only remaining issue related to thresholding was the "scaling" issue that had been discussed, and that Bob could handle that in an entirely separate BIRD once this [Pin Reference] BIRD clarified the proper way to make the measurements. Radek noted that he saw no real fundamental disagreement between Walter's and Bob's positions. Bob said he would review this latest draft 5 since his concerns were based on earlier drafts, and he said he would prepare a presentation on this topic for the next meeting. - Radek: Motion to adjourn. - Mike L.: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 12 July 2016 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives